Some computer related tasks, like software development and systems configuration, include modifying files like text files, data files, source code files, configuration files, and so on. The modifying may be done by a person and/or process who is not the author/creator of the file. When modifying, the modifier may not have and/or understand information concerning the modifications that they are making. Such knowledge, if it exists at all, likely resides in the accumulated expertise of the author/creator and/or a designer. Thus, some modifications may produce unexpected and/or undesired results. Unexpected and/or undesired results are also likely when the modifier is less proficient than the author/creator—if proficient at all—with the syntax, semantics, style, content, and so on of the file being modified. Even careful, complete, and systematic documentation by the author may not prevent such unexpected and/or undesired results.
While modifying a file, a change made by a user may render portions of the remainder of the file damaged, inoperative, and/or meaningless, thereby reducing and/or eliminating the purpose in configuring the affected portion(s). Conversely, a change made by a user may necessitate that other, related changes be made in other portions of the file. While the author/creator may at one point have understood these intertwinings, such relationships may become lost, or, to the end user, may never become known. Even if the relationships are well-documented, the modifier must still read, understand, and heed the directions. Thus, more unexpected and/or undesired results are likely.
Files associated with computer related tasks are typically not static entities. For example, an author/creator may revise their original creation (e.g., adding functionality to a device driver.) End users who wish to benefit from the revisions (e.g. bug fixes) must become aware of the update, evaluate whether it applies to them, understand what was changed, understand how it was changed, be able to effect the changes themselves, and so on. This is frequently a difficult task, if it can be performed at all. The difficulty of the task is complicated by the nature of computer files, where a change in one portion (e.g., data definition) can have ripple effects in other portions.
Conventional attempts to extract, maintain in a transferable form, undo, understand, and so on, changes made in a file include the use of “diff”, “delta”, and “patch” utilities, for example. Diff and delta utilities facilitate locating differences between files and changes made to files. Patch utilities facilitate taking discovered changes and applying them to other files. While such utilities may simplify finding modifications, conventionally they do not simplify understanding changes, and/or unwinding the changes.
Previous attempts to facilitate end user modification of source files without recoding the source files, or perhaps without even knowing how to recode the source file, have often left the end user with the ability to change a value in a file, but without any insights into what are acceptable values, why they are acceptable, what is recommended and so on. For example, U.S. Pat. No. 6,427,228, entitled Combining A Metadata File and Java Source Code To Dynamically Create Java Classes and JavaBeans, issued Jul. 30, 2002, concerns a technique for combining a metadata file and a Java source code to dynamically create Java classes and JavaBeans. While this increases flexibility by using placeholders for parameters in a main source code file and storing values to be substituted for the placeholders in an auxiliary file (e.g., metadata file), it does not help the author of the original file to convey information and/or control modifications of the original file. Furthermore, it does not guide the editor of the metadata file in understanding the configuration possibilities, or the consequences of configuration choices. Furthermore, attempts like that described in the '228 patent tend to be limited to macro expansions, which reduces the ability to parameterize file contents.
Other attempts to parameterize items (e.g., objects) have focused on supplying data, parameters, and/or values during and/or after item construction (e.g., object instantiation). Such attempts have employed diverse property mechanisms to parameterize component objects in an attempt to provide a uniform mechanism of accessing data. However, the user is often confronted with uninformed choices which, if handled poorly, can have negative impacts on the code, item, object, etc. that they desire to configure. For example, U.S. Pat. No. 6,226,692, entitled Method And System For Constructing Software Components And Systems As Assemblies Of Independent Parts, issued May 1, 2001, concerns assembling software components and systems from independent parts. While the mechanism can be employed for parameterization and serialization of objects, as well as providing structured storage, it leaves the configuring party (e.g., end user) directionless concerning the author/creator design decisions, documentation, guidelines, ranges, and so on.
Other attempts have been made to facilitate making quantified programmatic assertions over programs that otherwise are not annotated to receive assertions. These attempts try to facilitate describing desired behavior in a program without updating the actual program, or even without knowledge of how such an update would be made. For example, aspect oriented programming as described in Source-Code Instrumentation and Quantification of Events, Filman & Havelund, (2002), In Cytron, Ron and Leavens, Gary, Eds., Proceedings Workshop on Foundations Of Aspect-Oriented Languages, AOSD-2002, Twente, Netherlands., pp 45-49, describe adding event/action pairs to code to simplify customizing the behavior of programs. But, systems that employ, for example, sets of event/action pairs along with programs and/or compilers to analyze and/or process such pairs, may once again present a user with configuration choices without presenting the user with information, guidance, boundaries, recommendations, and so on, as produced by the original code author, that guide the user in making wise or appropriate choices. Thus, unreasoned configuration choices may be made, leading to unanticipated and/or undesired results.